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Summary 

The  following  report  details  the  progress  that  has  been  made  by  ASDL  in  developing  and 
applying  the  IRIS  concept  for  the  period  of  July  1  to  September  30,  2009.  The  major  task 
the  team  focus  on  is  to  develop  an  advanced  design  process  for  designing  intelligent 
complex  systems  with  “assess-prcdict-plan-execute”  functions,  such  as  next  generation 
naval  ship.  The  team  employed  UML  to  model  the  design  process  and  various  diagrams 
were  created  to  address  the  requirements  of  the  design  process  and  represent  the  design 
activities.  In  addition,  progress  is  made  on  individual  tasks,  including  initial  Paramarion 
drawing  for  notional  ship  design,  error  evaluation  in  the  integration  of  heterogeneous 
systems,  implementation  of  resource  allocation  in  high  level  controller,  distributed 
control  development  using  agent-based  control  with  inference  engine,  Python-based 
M&S  implementation  with  the  aid  of  graph-based  surrogate  modeling,  new  extension  of 
human  in  the  loop  control  and  method  development  for  improving  system  effectiveness. 

Task  1 :  Design  of  Integrated  Heterogeneous  Systems 

Subtask  1.1:  Design  Process  Development  Using  System 
Engineering  Approaches 

Subtask  1.1.1:  Method  Development  for  Complex  System  Design 
Introduction 

The  Integrated  Rcconfigurable  Intelligent  Systems  (IRIS)  is  an  initiative  employing 
advanced  methods  to  facilitate  the  design  and  operation  of  complex  intelligent  systems 
with  an  application  to  a  naval  ship.  These  systems  are  envisioned  to  perform  four  critical 
functions:  assess,  predict,  plan  and  execute.  The  implementation  of  these  functions 
involves  the  extensive  use  of  autonomous  decision  making  to  deal  with  various  scenarios. 
Traditional  methods  fall  short  of  adequately  addressing  all  the  capability  requirements 
within  the  stipulations  of  an  acceptable  cost.  Consequently,  new  design  processes  must 
be  developed,  implementing  the  methods  and  tools  necessary  to  design  systems  with 
respect  to  vital  global  behaviors.  In  the  past  few  years,  the  Aerospace  Systems  Design 
Laboratory  (ASDL)  at  the  Georgia  Institute  of  Technology  has  developed  a  Modeling  & 
Simulation  (M&S)  environment  based  on  a  reduced  scale  demonstrator  of  the  DDG-51 
class  chilled  water  system  to  investigate  the  system’s  behavior  when  coupled  to  a  variety 
of  control  and  decision  making  algorithms.  This  M&S  environment  is  a  key  enabler  that 
can  be  incorporated  in  the  design  process  for  analyzing  and  exploring  the  design  space. 
After  having  the  M&S  environment  available,  ASDL  has  initiated  plans  to  develop  an 
advanced  design  process  that  will  be  able  to  address  all  the  requirements  of  intelligent 
complex  systems  with  the  implementation  of  the  “assess-predict-plan-exccute”  functions. 

Progress 

In  order  to  develop  an  advanced  design  process  for  designing  intelligent  complex 
systems,  the  IRIS  team  has  agreed  to  utilize  Unified  Modeling  Language  (UML)  as  a 
means  to  document  the  systematic  approach  of  the  design  process.  UML  is  a  standardized 
general-purpose  object-oriented  modeling  language  used  to  specify,  visualize,  modify. 


construct  and  document  the  artifacts  of  an  object-oriented  software  system.  In  addition, 
UML  is  considered  as  an  appropriate  tool  to  describe  processes  and  has  been  widely  used 
in  business  process  modeling.  It  is  observed  that  if  the  process  is  fully  understood  and 
improved  before  a  project  is  started,  the  outcome  will  be  achieved  in  a  more  efficient  and 
effective  marmer.  As  an  extension  to  the  business  process  modeling  concept,  UML  is 
being  employed  to  formulate  the  IRIS  design  process.  Unlike  other  traditional  design 
processes,  the  IRIS  design  process  will  address  multiple  necessary  interfaces  actors  such 
as  the  stakeholders  at  each  design  step,  the  utilization  of  resources,  communications 
between  different  steps,  interrelations  between  models,  and  so  on.  That  is,  the  IRIS 
design  process  put  more  emphasis  on  how  exactly  the  activities  are  accomplished  rather 
than  what  needs  to  be  accomplished  in  each  design  step. 

As  a  first  step,  a  use  case  diagram  was  created  in  active  development  to  capture  the 
functionality  and  requirements  of  the  IRIS  design  process.  Four  high  level  use  cases  arc 
currently  identified:  build  system  ability  set,  design  architecture  concept,  establish 
baseline  and  build  system  model,  and  the  actors  interacting  with  these  uses  cases  are 
identified  as  well,  as  shown  in  Figure  1. 


Figure  1:  Use  Case  Diagram  for  IRIS  Design  Process 
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Figure  2:  Activity  Diagram  for  “Build  System  Ability  Set” 
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As  the  use  ease  diagrams  are  created,  they  will  be  analyzed  and  described  using  UML 
activity  diagrams.  Activity  diagrams  illustrate  what  needs  to  be  done  in  a  logical 
succession.  Because  each  activity  diagram  is  presented  in  a  relatively  more  detailed 
manner,  one  can  observe  all  the  dependencies  between  activities  in  a  graphic  form,  and 
enhance  the  ability  to  spot  where  changes  and  improvements  must  be  done.  Figure  2 
presents  the  activity  diagram  for  “build  system  ability  set”  use  case.  To  complete  this  use 
ease,  the  customer’s  requirements  arc  identified  first,  and  then  the  Quality  Function 
Deployment  (QFD)  technique  is  utilized  to  map  customer’s  requirements  to  system 
eharaeteristics.  Then  the  system  characteristics  will  be  defined  in  terms  of  abilities  and 
reviewed  with  customer.  If  changes  need  to  be  made  to  the  ability  set,  activities  will  be 
taken  to  add  or  remove  abilities.  After  the  system  ability  set  is  built,  the  abilities  will  be 
transferred  to  the  next  design  step  to  aid  further  design  decisions.  The  final  design 
solution  will  be  evaluated  against  these  abilities.  The  activity  diagrams  created  for  the 
other  three  use  cases  are  listed  in  the  Appendix,  showed  in  Figure  17  to  Figure  21. 

Activity  diagrams  model  the  logic  supporting  a  use  case  or  usage  scenario  and  shows  the 
overall  work  flow.  However,  it  is  not  capable  of  showing  the  detailed  interactions 
between  classes  and  the  message  flows  between  objectives.  This  information  can  be 
represented  in  communication  diagram  in  which  it  combine  the  information  from  class, 
sequence  and  use  case  diagrams  to  describe  both  the  static  structure  and  dynamic 
behavior  of  the  process.  We  also  created  communication  diagrams  for  each  use  eases  and 
they  are  illustrated  in  Figure  3,  Figure  4  and  Figure  5. 


Figure  3:  Communication  Diagram  for  “Build  System  Ability  Set” 
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Figure  4:  Communication  Diagram  for  “Generate  Baseline” 


Figure  5:  Communication  Diagram  for  “Build  System  Model” 
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Future  Work 

With  the  initially  created  diagrams,  future  work  regarding  this  task  will  be  to  iterate  upon 
these  diagrams  until  a  refined  version  of  the  method  is  manifested.  In  addition,  class 
diagram  will  be  studied  and  created  if  it  is  necessary  to  help  the  designer  recognize  how 
to  implement  the  process.  Finally,  all  the  diagrams  will  be  integrated  together  to 
formulate  the  design  process.  The  design  process  will  address  what  design  activities  need 
to  be  accomplished,  who  will  be  involved  in  each  activity,  what  information/resource  is 
required,  what  tool/method  will  be  utilized.  With  the  design  process,  designers/decision 
makers  should  know  how  to  design  their  own  intelligent  complex  system  which  is 
capable  of  providing  “assess-predict-plan-assess”  functions. 

Subtask  1.1.2:  Notional  Ship  Development 
Introduction 

As  it  has  been  discussed  in  the  original  FY  2009  proposal,  for  the  purpose  of  developing 
and  testing  the  proposed  design  process,  a  sizing  and  visualization  environment  is 
required.  This  environment  would  allow  for  a  ship  product  model  (PM)  development, 
starting  from  a  notional  baseline  and  furthermore  developed,  according  to  the  instructions 
applied  by  the  IRIS  method.  Complete  ship  configurations  would  be  identified  and  sized 
using  an  object-based  approach.  Eventually,  this  notional  ship  would  be  key  enabler  for  a 
set  of  studies  that  will  constitute  the  proof  of  the  IRIS  concept. 

Progress 

The  initial  scope  of  this  subtask  was  to  generate  a  computer  geometry  model  of  a  notional 
ship  (baseline  configuration),  using  Rhinoceros  3D®  as  the  primary  CAD  tool. 
Moreover,  a  dynamic  simulation  environment  of  the  ship  engineering  systems  is 
envisioned  to  be  built  around  it  for  analysis  of  operations. 

Meanwhile,  a  new  ship  sizing  and  design  tool  has  been  acquired  by  ASDL.  This  tool  is 
Paramarine,  developed  and  made  available  by  the  Graphics  Research  Corporation  (GRC). 
More  information  about  Paramarine  and  its  capabilities  can  be  found  at 
http://www.qinetiq.com/home_grc/products.html.  Given  the  superiority  and  the  offered 
analysis  possibilities  of  this  design  environment,  a  decision  has  been  made  to  implement 
a  ship  baseline  in  this  new  environment.  While  Rhinoceros  3D  is  an  excellent  graphical 
software  package,  it  appears  that  one  of  its  main  limitations  is  that  it  is  just  a  CAD 
environment,  without  any  embedded  modules  for  sizing  and  analysis  of  the  PM 
architecture.  On  the  other  hand,  a  PM  implemented  in  Paramarine  would  be  easily 
exported  to  solid  model  file  format  that  could  be  utilized  by  Rhinoceros  3D  and  further 
edited  as  a  CAD  model  for  any  other  purpose. 

Returning  on  the  objective  of  this  task,  the  original  proposed  idea  was  to  create  a  baseline 
notional  ship  that  would  be  heavily  based  on  a  YP-679  configuration.  Given  that 
available  engineering  system  models  are  sized  for  a  YP  sized  configuration  and  the 
Navy’s  interest  on  this  architecture,  the  choice  of  this  baseline  was  very  straightforward. 
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However,  basic  information  around  the  geometry  and  the  dimensions  of  the  YP-679  was 
sparse;  therefore  all  information  that  could  be  found  from  publicly  available  resources 
(web  search  for  reports,  schematics  and  fact  sheets)  has  been  imported  to  the  Paramarine 
PM  as  reference  information.  Notional  information  has  been  added  where  required 
information  cannot  be  available. 


Figure  6:  Early  Stages  of  a  Yard  Patrol  YP-679  Hull  Generation  in  Paramarine 
Future  Work 

Development  of  the  YP  -679  Paramarine  model  has  been  initiated  early  September  2009 
(Figure  6),  shortly  after  the  acquisition  of  the  software  tool  and  the  new  user  training 
course  that  occurred  in  August  2009.  This  task  is  planned  to  be  complete  by  early 
October  2009,  mainly  including  the  generation  of  the  hull,  internal  compartmentation  and 
subdivision,  as  well  as  engineering  systems  representation  (power  generation  and 
distribution,  cooling,  propulsion,  etc.). 

Subtask  1.2:  Integration  of  heterogeneous  dynamic  systems 

Introduction 

In  the  final  report  for  2008,  the  initial  steps  for  the  time-discrete  integration  and  co¬ 
simulation  of  different  confidential  third-party  dynamic  models  have  been  presented. 
Conditions  regarding  constraints  between  the  models  were  discussed.  It  was  observed 
that  the  simulation  of  dynamic  systems  on  a  digital  computer  can  only  be  executed  at 
discrete  time  steps.  Variable/adaptive  time  step  algorithms  have  been  presented  which 
enable  the  simulation  to  run  in  a  shorter  time  and  at  greater  accuracy.  Models  were 
developed  to  investigate  and  demonstrate  the  feasibility  and  viability  of  the  selected 
approaches.  The  results  showed  that  the  approach  of  using  variable  time  steps  is 
promising.  Accuracies  and  run  times  were  greatly  improved.  The  application  of  a  simple 
algorithm  is  comparatively  easy.  No  optimizations  have  been  made  yet. 
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Progress 

One  problem  of  eo-simulation  with  proprietary  sub-models  is  the  evaluation  of  the 
resulting  eombined  model.  The  behavior  of  the  eombined  model  is  by  definition  not 
known.  Hence,  assumptions  and  approximations  must  be  made  in  order  to  determine 
whether  the  observed  model  behavior  is  within  the  expeeted.  Speeifieally,  an  error  must 
be  estimated.  Ideally,  the  error  should  not  only  be  estimated,  but  error  bounds  should  also 
be  given.  This  would  enable  the  algorithm  to  determine  whether  the  simulation  still 
behaves  as  expeeted.  In  order  to  evaluate  the  error  and  its  bounds,  a  mathematieal 
approaeh  is  suggested  that  eombines  eoneepts  of  numerical  integration  and  polynomial 
interpolation  to  find  a  simulation  path  that  eomes  elosest  to  the  estimated  system 
behavior.  The  suggested  approaeh  eonsists  of  an  interpolation  of  previous  points,  the 
estimation  of  a  local  slope  that  translates  best  to  the  system  behavior  in  the  next  point  in 
time,  and  a  Taylor  theorem  approach  to  the  estimation  of  the  funetion  and  the  error. 

Figure  7  shows  the  cause  of  error  in  the  evaluation  of  a  differential  equation.  The 
approach  is  the  Euler  method,  the  simplest  way  to  numerieally  integrate  such  a  function 


Figure  7:  Cause  of  Error  in  Numerical  Integration 

It  is  clear  that  as  long  as  the  seeond  derivative  of  the  underlying  function  is  not  changing, 
the  error  will  continue  to  increase.  It  is  also  clear  that  reducing  the  time  step  will  decrease 
the  error.  However,  ideally  the  time  step  should  be  large  in  order  to  reduee  the  amount  of 
calculations.  Henee,  a  new  approach  ean  be  evaluated  that  tries  to  improve  and  somewhat 
forecast  a  better  slope  at  the  current  position,  in  order  to  be  able  to  get  a  better 
approximation  of  the  underlying  funetion.  Figure  8  shows  an  approaeh  that  uses  future 


8 


simulation  outputs  to  determine  a  better,  more  aeeurate  slope.  This  approaeh  is  the 
Heun’s  method,  or  Runge-Kutta  2. 


This  approach  can  be  extended  to  more  points  evaluated  for  slope  approximation, 
resulting  in  higher-order  methods.  However,  this  alone  does  not  yet  give  an  error  or  an 
error  bound.  However,  the  approaeh  in  Figure  8  and  other  higher-order  methods  of 
similar  approaeh  are  based  on  the  approximation  of  a  function  using  a  Taylor  series  and 
Taylor’s  theorem.  This  theorem  is  mathematically  well  defined,  and  allows  for  both  error 
estimation  and  error  bounding.  The  approaeh  uses  similar  techniques  that  are  used  in 
numerical  integration.  It  derives  the  approaeh  using  first  principles  of  numerical 
integration,  and  extends  those  principles  to  the  eo-simulation  of  several  dynamic  systems. 
It  unites  the  integration  techniques  with  the  Taylor  theorem  to  not  only  estimate  the 
closest  point  as  the  next  step  in  the  simulation,  but  to  also  give  an  error  estimate,  based 
on  which  it  will  be  possible  to  optimize  the  simulation  execution  time  and  error,  and  to 
react  upon  shock  impacts  that  may  come  from  within  the  system  or  from  external  factors. 
Previous  points  will  need  to  be  regressed  or  otherwise  approximated,  adding  an 
additional  error  that  will  need  to  be  specified  and  bounded.  Like  the  simple  variable  time 
step  in  previous  discussions,  this  approach  will  be  tested  with  a  simple  model  at  first,  and 
then  extended  to  a  system  that  consists  of  several  sub-systems  with  different  system 
frequencies,  making  the  overall  system  a  stiff  system.  This  approach  is  currently  under 
development,  and  will  be  a  Ph.D.  thesis  for  one  of  the  members  of  the  IRIS  team  (Matt 
Hoepfer). 
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Future  Work 

Within  the  next  three  months,  the  mathematieal  prineiples  of  the  suggested  approaeh  will 
be  eolleeted,  refined,  and  synthesized  to  an  overall  approaeh  for  eo-simulation.  A  simple 
model  to  test  the  approaeh  already  exists,  and  will  be  modified  to  inelude  the  new 
mathematieal  methods.  Further  down  the  road,  a  more  eomplieated  and  realistie  model 
will  be  developed,  whieh  will  represent  a  ship  system  and  whieh  will  serve  to  evaluate 
the  approaeh  and  make  sure  that  it  is  applieable  beyond  a  “lab”  environment.  Further 
investigations  will  inelude  issues  with  time  steps  and  data  exehange  sehedules  in  stiff 
systems,  as  these  issues  may  eause  further  problems  in  a  real  world  simulation.  Also,  the 
upper  and  lower  bounds  for  time  steps,  and  the  algorithms  for  time  step  settings  will  be 
evaluated  and  tested. 

Task  2:  Intelligent  Autonomous  System 
Subtask  2.1:  High  Level  Control 
Introduction 

Since  the  IRIS  designed  systems  are  eomplex  in  nature,  the  system  often  eonsists  of 
multiple  subsystems  whieh  provide  neeessary  funetionalities  to  the  system.  As  a  result, 
various  subsystems  work  together  to  aehieve  the  overall  operational  goal  of  the  system, 
therefore,  a  tradeoff  analysis  should  be  conducted  across  the  multiple  objectives  to 
optimize  the  objective  of  the  system.  As  a  result,  proper  decisions  need  to  be  made  from  a 
systems  point  of  view  to  keep  the  system  working  functionally  and  effectively. 

The  high  level  control  of  the  M&S  environment  is  responsible  for  prioritizing  the 
subsystems  on  resource  allocation  using  dynamic  decision  making  and  control 
approaches.  In  the  implementation,  the  high  level  controller  will  assign  priorities  to  the 
services  loads  and  determine  the  appropriate  actions  needs  to  be  taken  in  order  to 
effectively  distribute  multiple  resources. 

Progress 

A  rule-based  high  level  controller  is  employed  to  set  priorities  for  service  loads  requiring 
cooling  resources.  It  ean  decide  what  is  important  at  whieh  point  in  time,  and  how 
important  in  comparison  to  others  on  obtaining  required  resources.  This  prioritization  is 
based  on  the  evaluation  of  operating  environment,  ship  status  and  mission  being 
perfonned.  In  addition,  an  approaeh  that  uses  an  optimization  function  that  takes  into 
account  relevant  system  parameters  and  mission  status  was  also  investigated.  It  was 
found  that  the  rule  based  controller  is  effective  in  making  autonomous  decision  and  easy 
to  be  implemented  when  allocating  a  single  resource  to  service  loads. 

The  rule-based  high  level  controller  possesses  a  certain  degree  of  intelligence  when 
deciding  on  the  load  prioritization.  It  makes  decisions  guiding  the  resource  allocation 
based  on  the  mission  that  the  ship  is  performing  and  the  resource  status  a  service  load 
has.  It  determines  the  priority  in  which  a  service  load  get  resource  by  evaluating  how  a 
service  load  is  important  to  best  perform  the  current  mission  based  on  the  situation  at 
hand.  It  also  depends  on  if  a  service  load  requires  resource  urgently.  For  instance,  if  a 
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load  has  high  priority  because  it  is  critical  to  the  operation  of  other  subsystems  and  based 
on  the  mission  status,  but  this  load  has  a  large  margin  before  it  reaches  a  critical  stage 
(e.g.  not  extremely  hot  but  running  at  a  regular  operating  temperature),  then  it  makes 
sense  to  save  some  of  the  resources  and  not  provide  this  load  with  further  resource.  This 
will  be  achieved  by  providing  two  outputs  from  the  high  level  control  module:  a  priority, 
and  a  control  action  recommendation  (i.e.,  percentage  of  the  maximum  resource 
requirement  of  the  service  load).  This  control  action  increases  as  the  load  approaches  a 
critical  operating  condition  within  a  safety  margin.  This  decision  making  strategy 
implemented  in  the  high  level  controller  is  effective  and  results  show  it  ean  increase  the 
efficiency  of  resource  usage. 

Future  Work 

Further  work  will  foeus  on  investigating  and  utilizing  more  advanced  decision  making 
and  control  methods  to  deal  with  the  resource  allocation  problem.  The  method  needs  to 
be  effectively  to  manage  multiple  resources  and  account  for  the  interactions  between 
resources. 

Subtask  2.2:  Multi-Agent  Based  Mid-level  Control  with  Dynamic 
Inference  Engine 

Introduction 

The  objective  of  this  research  is  to  develop  a  comprehensive,  generalized  framework  for 
the  control  system  design  of  a  general  large-scale  complex  system  under  significant 
uncertainties,  with  the  foeus  on  distributed  control  architecture  design  and  distributed 
inference  engine  design. 

Progress 

Hybrid  Multi-Agent  Based  Control  (HyMABC)  architecture  is  proposed  via  combining 
hierarchical  control  architecture  and  module  control  architecture  with  logical  replication 
rings.  A  Multiple  Sectioned  Dynamic  Bayesian  Network  (MSDBN)  as  a  distributed 
dynamic  probabilistic  inference  engine  ean  be  embedded  into  the  control  architecture  to 
handle  uncertainties  of  general  large-scale  complex  systems.  MSDBN  decomposes  a 
large  knowledge-based  system  into  many  agents.  Each  agent  holds  its  partial  perspective 
of  a  large  problem  domain  by  representing  its  knowledge  as  a  Dynamic  Bayesian 
Network  (DBN).  By  using  different  frequencies  for  local  DBN  agent  belief  updating  and 
global  system  belief  updating,  communication  cost  and  inference  global  consistency  can 
be  effectively  balanced.  In  this  research,  fully  factorized  Boyen-Koller  (BK) 
approximation  algorithm  is  used  for  local  DBN  agent  belief  updating,  and  static  Junction 
Forest  Linkage  Tree  (JFLT)  algorithm  is  used  for  global  system  belief  updating. 

MSDBN  assumes  static  structure  and  stable  communication  network  for  the  entire 
system.  However,  for  a  real  system,  sub  Bayesian  network  as  a  node  eould  be  lost,  and 
communication  network  eould  be  shut  down  due  to  partial  damages  in  the  system. 
Therefore,  on-line  and  automatic  MSDBN  structure  formulation  is  necessary  for  making 
robust  state  estimations  and  increasing  survivability  of  the  whole  system.  Distributed 
Spanning  Tree  Optimization  (DSTO)  algorithm.  Distributed  D-Sep  Set  Satisfaction 


(DDSSS)  algorithm,  and  Distributed  Ruiming  Intersection  Satisfaction  (DRIS)  algorithm 
are  proposed  in  this  research.  Combination  of  those  three  distributed  algorithms  and 
Distributed  Belief  Propagation  (DBP)  algorithm  in  MSDBN  makes  state  estimations 
robust  to  partial  damages  in  the  whole  system. 

Combining  the  distributed  control  architecture  design  and  distributed  inference  engine 
design  together  leads  to  a  formal  procedure  of  control  system  design  for  a  general  large- 
scale  complex  system  as  shown  in  Figure  9. 
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Figure  9:  Process  of  Control  System  Design  for  Large-Scale  Complex  Systems 


In  order  to  check  the  effectiveness  and  validity  of  the  proposed  methodology  and  process 
and  show  how  to  implement  the  process  step  by  step,  the  control  system  design  of  a 
simplified  ship-wide  Chilled  Water  System  (CWS)  is  used  as  a  proof  of  concept. 
Currently,  the  sketch  of  the  implementation  has  already  been  formed  and  most  part  of  the 
coding  is  finished. 


B  J  A6D1I 

'.f.  ^  chl««Clot«Piob{1] 

•ii  chiwConmnd(1] 
cHI«rOp«nO(gr««j1j 
p’  chfciOp«nPiob(1] 

«  P  chil(ii$luckOoMP(ob{1] 

P  chlHShjckOperf*Tobn] 

•u  d«itaT 
«  ^  HoMat6(21I 
,1'  p  pijmpC1osePlob{2) 

*  p  pumpCofnmand(2] 

*  pump0p«n0agtM{2] 

P  pumpOpenPiobp) 

p  punpStuckCIo<«Ptob{21 
^  pumpShjck0p«nP«ob{2| 

*  rM«uc«Cap4ci()^1 ) 

*  ttnsadChiefOpKnOagiMlI  ] 

■*  -Mi 

*  >ens«(f\fnp0pen0egree{2) 

Mnt«(V«lv«0penDe9ee(14] 

*  wfv»cetea(fnonfy(2l 

*  p  nryic0laadReq(2] 

smTitw 

■MSI  Hruciu«FM«naCool 
««  stiuctueFiaNameHol 

JS-t 

■MJ  tO 

>.  p  vatveCloMPiob{14] 

\  P  vaiveCoiTin)and(14] 

*  p  valve0p«n0egree(14] 

S  p  vatve0penPiob{t4) 

t  p  valv«Stuckao*ePT0t){14) 

T  p  vaiveStuck0penPiob(14) 

S  CWS 
.1  4.  T£S 

1-  ScendnoOei¥iemen(AJ^en4^^ 

Sceoano 


Scanerto 

Hwpr«t  Scenario* 


iBaaid 

idOynacic 


JtvtennPlug.^ 
Mii>.A9*r« 
SacUontd 
hfaranca  En^ 
Inferenca  Enghe 
incoit*)Ma 
KMa 
(tsirbiedway 


niormaltotio 


Cortraiyy«iMul*)ta 
Bayacian  Nat  work* 

colect*  ixKadainand 
and  (sad*  eatmated 
cortrotagants  Ina 


MaBab  Scrlr4  Pkjg-r 
Thermo-Sadrlcal  Model 

I  samMaa  power  componart  tamparatura  changes 
accordng  to  ktcoiwng  power,  power  efficiency.  Incoming 
cooing  fluid  flow  rate*  and  other  charadanatics  of  a  set 
of  power  coaiponarts 

I  alao  calcuMaa  the  raquirad  cooing  fhjd  flow  rates  by 
using  condbn-besed  proportional  coitrol  method 


§Mfl7  \ 
CWS 


Vlaual  Basic  Applcahon  Plug-in  eased  Off  Com  Obfect 
CMadVIMsr  System 

I  smiates  a  cooing  network  consistrig  of  pa)as, 
punps,  vatvas  and  raaarvoks,  heel  axchangers,  sic 
I  can  take  cortrol  stgnaia  for  opersirig  vatves,  pumps, 
ha«4  exchangers  sic 

I  can  provide  flow  rates,  pressures,  temperatures  at 
diffarart  nodes  r  the  rratwork 


Excel  Phjg-in 

Define  diftarert  acanarios  over 
cartari  fane  span 
Colact  sfisJaiion  rasiAs  over 
certain  time  apan  and  viaualza 


ScenanoOafmamantAndResLdCoSoctnn 


Figure  10:  The  Entire  Test  Model  in  ModelCenter  Analysis  View 
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The  integrated  model  shown  in  Figure  10  will  be  briefly  discussed  in  this  report  and 
detailed  discussion  of  every  module  will  be  in  the  final  report.  The  integrated  model 
includes  five  modules:  Scenario,  ABCtrl,  CWS,  TES  and 

ScenarioDefinementAndResultCollcction.  Scenario  module  transforms  the  scenarios 
defined  in  ScenarioDefmementAndResultCollection  module  into  the  format  which  is 
compatible  with  CWS  module  created  in  Flowmaster.  ABCtrl  includes  HyMABC  and 
MSDBN,  which  consist  of  dozens  of  control  agents  and  three  Bayesian  network  agents. 
The  internal  structure  of  each  Bayesian  network  agent  and  the  relationships  among  them 
are  shown  in  Figure  1 1.  All  of  the  agents  are  established  in  JADE  which  is  completely 
implemented  in  Java  language,  while  CWS  simulates  fluid  network  which  balances 
energy,  pressure  and  mass  flow  rate  of  fluid.  TES  is  a  thermoelectric  model  and  it  also 
includes  low  level  feed  back  controllers.  ScenarioDefinementAndResultCollcction  is 
implemented  in  Excel  worksheet.  It  defines  the  scenarios,  collects  the  simulated  results 
and  visualizes  the  results. 


Figure  11:  MSDBN  of  the  Simplified  Chilled  Water  System 
Future  Work 

As  mentioned  before,  the  sketch  of  the  implementation  has  already  been  formed  and  most 
part  of  the  coding  is  finished.  Further  debugging  and  coding  will  be  continued  in  the 
following  3  months.  Data  collection  and  data  analysis  will  be  carried  out  in  the  near 
future. 
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Task  3:  Graph-Based  Component  Surrogate  Modeling 

Background 


The  task  goal  is  to  develop  a  M&S  method  of  a  chilled-water  network  that  is  capable  of 
taking  the  connection-topological  configuration  among  the  components  of  the  network  as 
a  “design  variable.”  Then  integrated  the  design-space  exploration  or  the  design 
optimization  process,  this  proposed  M&S  environment  may  enable  a  simulation-based 
design  for  resiliency  and  survivability.  The  method  consists  of  three  key  ideas  -  a  graph- 
based  topological  modeling,  object-oriented  component  model  definition,  and  surrogate 
modeling  for  representing  components’  behaviors.  Though  the  development  of  the 
method  is  based  on  the  application  for  fluid  systems  modeling,  the  development  approach 
has  also  considered  more  extended  uses  including  the  application  to  an  electric  power 
network  which  is  another  most  common  type  of  physics  networks  in  engineering  systems, 
just  with  minimal  modifications  of  the  method. 

Progress 

The  blue  print  of  the  M&S  method  was  developed  previously  so  the  task  during  the  last  3 
months  has  been  on  the  implementation  of  the  method  with  the  chilled-water  system  of 
the  notional  YP  as  the  modeling  example. 

As  the  development  environment  of  M&S,  Python  script  language  was  chosen.  The  early 
proof-of-concept  model  was  implemented  with  Matlab,  but  as  the  task  progressed, 
Matlab  was  found  to  be  inadequate  as  the  development  environment  of  the  graph-based 
component  surrogate  modeling  method  since  Matlab  is  inherently  not  designed  to 
perform  object-oriented  coding  (although  its  late  versions  have  object-oriented  coding 
features)  and  as  a  result  is  less  capable  of  creating  a  model  with  dynamic  topological 
changes.  Compared  to  Matlab,  Python  is  object  oriented  but  is  also  a  script  language  like 
Matlab,  which  makes  it  easier  to  learn  and  maintain  than  other  lower  level  object-oriented 
programming  languages  such  as  C-H-  or  Java.  Python  also  features  a  Matlab-like 
interactive  shell  and  matrix  data  structures  with  a  proper  configuration  becoming  a  great 
Matlab  alternative. 

The  progress  of  the  task  on  the  Python-based  M&S  implementation  can  be  divided  into 
five  phases: 

Phase  1 :  Development  and  test  of  the  basic  classes  for  a  simulation  environment  like 
a  solver  and  a  data  manager  and  the  classes  of  the  graph  elements  such  as  nodes, 
edges,  sources,  sinks,  and  damages. 

Phase  2:  Development  of  the  damage  scenario  generator  class  and  test  of  the  damage 
simulation  of  the  M&S  environment 

Phase  3:  Development  and  test  of  a  “prefect”  damage  controller. 

Phase  4:  Development  and  test  of  the  experimental  design  class  for  the  network 
topological  space. 
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Phase  5;  Building  the  model  of  the  ehilled-water  system  of  the  notional  YP  and 
demonstration  of  damage  analyses  and  topological  design  space  exploration. 


Currently,  the  progress  of  Phase  1  is  over  90%,  Phase  2  about  70%  and  Phase  4  about  40% 
eompleted  (the  pereentage  numbers  are  subjeetively  estimated).  A  simple  model  used  for  the  proof  of 
eoneept  in  the  previous  works  was  reereated  in  this  M&S  environment,  and  the  simulation  for  both  a 
normal  operation  eondition  (i.e.  no  damage)  and  a  damaged  eondition  was  run  with  sueeess. 
Figure  12  is  a  UML  class  diagram  of  the  M&S  environment  built  with  Python  for  the 
fluid  system.  This  diagram  is  not  yet  eompleted  so  it  is  subject  to  change  as  the  task 
moves  forward.  Future  changes  will  include  additional  classes  for  the  eontrollers  and  the 
further  development  of  the  classes  in  post _proc  module. 


Figure  12:  Class  Diagram  of  M&S  Environment 

Although  the  result  of  the  eode  is  only  marginally  valid  for  debugging  proeess.  Figure  14 
and  Figure  15  are  only  presented  for  the  demonstration  purpose.  Figure  13  shows  the 
location  of  a  single  damage  applied  in  the  simulation.  The  model  is  under  a  normal 
operation  condition  with  a  pump  running  at  about  3000  rpm,  and  then  the  damage  oceurs 
at  2  sec.  of  the  simulation  time.  The  model  in  the  simulation  has  shown  quite  reasonable 
responses  in  generally  but  there  are  several  points  that  need  to  be  debugged.  In  Figure  14, 
the  flow  rates  at  the  service  loads  1  and  3  drops  significantly  with  the  drop  of  the  inlet 
pressure  when  the  damage  happens.  At  the  same  time,  the  water  is  being  lost  through  the 
ruptured  ends  of  the  damaged  pipelines  with  a  lot  higher  flow  rates  than  the  ones  of  the 
pipelines  maintained  in  undamaged  condition. 
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Figure  13:  Damage  Given  in  Simulation 


The  qualitative  behaviors  of  the  model  seem  correct  but  the  numerical  result  still  has 
large  errors.  This  is  mainly  because  the  surrogate  models  are  not  accurate  enough.  Just 
for  the  sake  of  spending  minimal  efforts  in  the  debugging  process,  the  surrogate  models 
used  in  the  simulation  were  not  generated  with  rigorous  fine-tuning  and  validation 
processes  result  in  large  numerical  errors  in  the  simulation.  This  problem  will  be  however 
corrected  as  more  accurate  surrogate  models  will  be  created  in  the  final  demonstration.  In 
Figure  15,  there  is  a  strange  overshot  of  the  water  flow  rates  at  the  ruptured  ends  of  the 
low-pressure  pipelines  (i.e.,  pipe_lp_nw  and  pipOp_sw),  which  should  be  corrected  by 
further  debugging  efforts. 


Figure  14:  Flow  rate  and  Inlet  Pressure  to  Service-Load  Pipelines  1  and  3 
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Figure  15:  Flow  rate  and  Pressure  at  the  Pipes  near  Rupture 
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Future  Work 

As  briefly  mentioned,  the  future  work  will  mainly  foeus  on  Phase  3,  Phase  4  and  Phase  5, 
eoding  for  M&S  implementation.  Phase  5  is  all  about  the  test  and  demonstration  of  the 
final  version  of  the  M&S  environment  which  will  therefore  be  the  deliverable  results. 
One  or  two  submissions  for  publieation  are  plaimed,  and  at  least  one  will  be  submitted  by 
the  end  of  this  year. 


Task  4:  Human  in  the  Loop  Control 

Introduction 

The  HMI  was  originally  written  in  pure  JavaScript  as  a  first  step  to  understanding  how  an 
AJAX  style  web  applieation  might  enable  human-in-the-loop  eontrol.  The  applieation 
included  many  features  to  faeilitate  its  use  within  the  design  cyele.  Some  of  these  features 
included  a  simple  and  easy  to  understand  user  interfaee  and  accessible  eonfiguration  files 
stored  on  an  applieation  server.  Although  the  first  version  was  very  sueeessful,  the 
expansion  of  the  original  proved  to  be  diffieult.  Maintenance  issues  raised  as  it  was 
learned  how  dependent  JavaSeript  was  from  browser  to  browser,  or  even  differing 
versions  of  the  same  browser.  In  response  to  these  impediments  it  was  proposed  to  port 
the  eode  base  from  JavaSeript  to  a  Flex-framework  implementation.  This  shift  would 
provide  many  advantages  including  the  opportunity  to  compile  the  code  permitting  a 
more  stable  maintenance  condition. 

Progress 

Progress  for  this  task  ean  be  broken  into  four  categories.  The  first  category  is  the 
development  of  the  basic  libraries  that  will  serve  as  the  foundation  for  the  whole 
applieation.  The  second  category  is  eoneemed  with  the  recovery  of  the  initial  capability 
of  the  original  version  of  the  HMI.  The  third  category  is  involves  the  expansion  upon  the 
original  capabilities.  The  finial  and  most  essential  category  is  that  of  documentation. 

The  basic  libraries  are  under  current  development  and  being  documented  in  parallel.  The 
complete  list  of  classes  under  the  HMI  library  presently: 

•  dashML  (handles  communications  with  the  server  during  runtime) 

•  dateToEnglish  (translates  dates  and  times  into  terms  of  years,  months,  weeks, 
days,  hours,  minutes,  seconds) 

•  E4XParser  (XML  Parser) 

•  simComponent  (graphical  widgets  for  simulations) 

•  simComponentCanvas  (canvases  for  graphical  widgets) 

•  simDataManager  (handles  static  and  dynamic  datasets  for  simulations) 

•  svgCompilerAgent  (handles  server  side  compiler  events  during  runtime) 

•  winManager  (handles  windowing  system  and  multi-tasking) 

•  xml2xml  (translates  between  multiple  xml  schemas) 


17 


These  libraries  handle  all  the  fundamental  operations  and  functionalities  of  the  HMI 
client.  At  this  point  these  support  the  full  capabilities  of  the  original  HMI,  but  they 
remain  under  development  for  future  capabilities. 

The  newer  Flex  based  implementation  is  required  to  reproduce  all  the  capabilities  of  the 
original  version.  The  most  recent  advancements  meet  this  standard  with  room  to  grow. 
These  capabilities  being; 

•  Centralized  code  base 

•  Serve  multiple  clients  simultaneously 

•  Hybrid  server  side  and  client  side  web-applieations 

•  Object-Oriented  Programming 

•  Scalable  Vector  Graphics 

•  ModclCcntcr™  Simulation  Plug-in 

•  Real  time  user  interface 

•  Ready  to  use  out  of  the  box  (distributed  as  a  virtual  machine) 

Despite  these  accomplishments  both  the  original  and  the  new  version  lack  adequate  error 
handling  and  logging.  The  new  version  does  in  fact  comprise  the  ability  to  catch  errors 
without  crashing  (most  of  the  time),  but  it  lacks  a  logging  system  altogether.  Thus  every 
error  is  immediately  brought  to  the  user’s  attention  even  if  the  error  is  not  critical.  During 
other  instances  the  errors  are  not  detailed  enough  to  provide  any  real  meaning. 

The  expansion  effort  to  increase  the  current  capabilities  has  been  approached  from  three 
fronts.  The  first  major  extension  is  the  integration  of  the  HMI  with  a  SQL  database.  The 
database  will  provide  the  infrastructure  for  the  storage  and  retrieval  of  complex  data 
structures.  This  means  more  complex  configurations,  management,  and  data  handling. 
These  plans  will  enable  some  of  the  more  advanced  feature  such  as  multi-eoncurrcnt-user 
handling,  TiVo  like  functions  for  time  domain  simulations,  and  the  archiving  of 
simulation  data  and  user  interaction  data  for  post  analysis. 

The  databases  basic  interfaces  are  in  place,  with  a  few  more  advanced  interfaces  for  more 
specialized  tasks.  The  database  schema  is  still  in  its  first  iteration  with  only  basic 
functions  in  service.  MySQL  is  currently  being  used,  but  the  schema  design  is  compatible 
with  other  database  systems  with  very  minor  changes  required. 

Future  Work 

Task  4  is  running  on  time  following  closely  to  the  proposed  plan  described  in  the  2009 
statement  of  work.  However  two  issues  have  arrived  that  require  further  attention.  The 
most  pressing  is  a  more  advanced  error  handling  and  logging  mechanizes.  It  would  be 
desirable  to  categorize  the  errors  in  order  to  maximize  their  usefulness  to  the  users.  It 
would  also  be  useful  to  create  a  hybrid  logging  system  that  is  keep  by  both  the  client 
application  and  the  server.  This  arrangement  could  help  troubleshoot  communication 
errors  of  the  network. 

The  second  issue  relates  to  the  sealable  vector  graphics  (SVG)  render.  The  original 
version  of  the  HMI  used  the  web  browsers  ability  to  render  SVG.  This  is  no  longer 


18 


available  in  the  Flex  framework.  Some  sueeess  had  been  made  using  another  open-souree 
SVG  render,  however  the  projeet  did  not  fully  support  all  the  eapabilities  of  SVG  and  the 
projeet  reeently  has  ehange  direetions  and  goals.  Unfortunately,  the  new  direetion  is  not 
eompatible  with  the  HMI.  Currently  we  are  looking  at  a  more  advaneed  render,  however 
this  render  most  be  exeeuted  on  the  server.  This  solution  seems  viable  sinee  these 
renderings  only  need  to  be  eompiled  during  eonfiguration  time.  Onee  the  renderings  are 
eompiled  the  elient  ean  manipulate  the  images  loeally  without  burdening  the  server. 

Task  5:  A  Methodology  for  Improving  System 

Effectiveness  in  Resilient  Systems  Design 

Subtask  5.1:  Theoretical  background  and  framework 

development 

Introduction 

Aeeording  to  literature,  there  have  been  several  survivability  evaluation  frameworks  that 
have  been  used  for  assessing  survivability.  Sueh  frameworks  typieally  inelude  input 
metries,  parameters,  response  metries  and  relationships.  In  order  to  propose  and  establish 
the  theoretical  framework,  the  basis  of  its  realization  should  rely  on  the  fact  that  there  is  a 
minimum  set  of  engineering  subsystems  that  are  required  for  supporting  basic  system 
operations  and  functions.  Sueh  functions  could  be  to  provide  electric  power,  mobility, 
cooling  and  control.  To  generalize  this  claim,  two  “functionally  similar”  systems  ean  be 
formulated  to  generate,  distribute  and  deliver  a  value  (electrical  or  mechanical  power  or 
information)  to  a  recipient.  Given  that  system  effectiveness  is  directly  dependant  to  how 
systems  ean  maintain  their  ability  to  perform  sueh  functions  under  any  environmental 
conditions,  similar  factors  and  metries  will  be  responsible  for  system  survivability.  A 
subset  of  this  environment  should  be  a  set  of  description  variables  and  parameters  for 
representing  the  effect  of  system  threats,  hazards  and  faults.  With  this  subtask,  a  survey 
and  a  tabulated  classification  of  possible  threats  that  a  system  ean  encounter  will  be 
eonstmeted.  A  pattern  will  be  investigated  for  scenario  prescribed  system  attack  or 
impact  similarities.  Based  on  observations,  threat  taxonomy  ean  be  created,  based  on  the 
response  that  they  induce  to  a  system. 

Progress 

It  has  been  identified  that  the  basic  information  around  a  complex  system  that  this 
framework  is  called  to  be  able  to  describe,  should  contain  the  following: 

•  System  Geometry  and  Specifications  (Drawings,  CADs,  pictures,  product  models) 

•  Engineering  Subsystems 

o  Types  (electrical,  meehanieal,  hydraulic) 
o  Geometry  (specs,  topologies,  engineering  sketches) 
o  Performance  ratings 
o  Cost 

o  Connectivity 
o  System  states 
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•  Mission  profiles 

o  Goals  and  objectives 
o  Figures  of  merit 
o  Time  frames 

•  Threats  and  hazards 

o  Types 

o  Impact  data  and  models 
o  Failure  rates  and  modes 
o  Response  and  recovery  times 

Under  construction  is  a  list  for  possible  threat  identification.  This  is  essentially  a 
tabulation  of  intelligent/non-intclligcnt  threats  vs.  the  three  main  types  of  change, 
context,  expectation  and  form  of  the  physical  system.  The  next  step  (also  currently  under 
development)  is  a  Microsoft  Excel  template  to  host  a  compatibility  matrix  of  threats  to 
system  and  subsystem  types. 

Future  Work 

The  scope  of  this  task  is  to  deliver  a  framework  of  metrics,  parameters  and  relationships 
that  would  support  system  survivability  evaluations,  including  subsystem  degrees  of 
freedom,  response  metrics  and  relationships/bonds  that  can  capture  causality  and 
subsystem  interaction  at  a  minimum.  The  framework  will  be  defined  in  an  object  oriented 
modeling  environment,  such  as  UML  and  SySML,  comprised  of  class  definition,  activity 
and  communication  diagrams. 

Subtask  5.2:  Formulation  of  analysis  tools  and  integration  into  a 
M&S  environment 

Introduction 

Individual  models  of  engineering  subsystems  are  combined  to  produce  integrated  models 
for  dynamic  simulation.  Part  of  this  particular  effort  will  be  a  routine  that  models  and 
investigates  damage  propagation  on  a  naval  system.  The  damage  model  engine  will 
analyze  (damage  prediction)  and  visualize  (on  the  Paramarine  ship  PM)  the  damage 
propagation  throughout  the  particular  architecture.  In  this  task,  a  total  ship  systems 
operations  M&S  environment  is  the  desired  outcome,  including  an  investigation  of 
damage  generation  and  propagation. 

Progress 

For  the  purpose  of  understanding  model  how  damage  on  a  system  occurs  and  propagates, 
several  theoretical  models  have  been  considered  and  processed.  The  most  common 
mechanism  for  damage  propagation  is  when  systems  are  directly  connected  and 
immediately  affected.  With  a  given  initial  point  of  damage  (e.g.  faulty  node)  in  a  systems 
network,  there  can  be  a  direct  prediction  of  what  other  nodes  will  be  affected.  A  common 
approach  for  this  prediction  is  the  usage  of  deactivation  diagrams. 

However,  there  is  another  mechanism  that  can  reveal  more  consequences  on  system 
performance,  due  to  the  occurrence  of  a  damaged  subsystem.  Emerging  behaviors  can 
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trigger  further  eomplieation  in  normal  system  operation  and  propagate  the  effects  of 
initial  damage  to  system  network  neighborhood  that  is  either  physically  far  from  the 
initial  damaged  point  or  not  necessarily  physically  connected  to  the  faulty  component.  A 
dynamic  simulation  of  systems  operation  is  expected  to  reveal  the  final  set  of  affected 
subsystems  and  compartments,  in  order  to  identify  the  ship’s  overall  performance 
capability  at  the  point  that  damage  has  propagated  to  great  extent. 

The  above  scheme  is  briefly  described  in  the  following  schematic  (Figure  16). 
Ultimately,  the  results  of  the  dynamic  simulation  will  be  processed  in  order  to  identify 
any  possible  directions  of  improvement. 
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Figure  16:  Modeling  &SimuIation  Environment  for  Survivability  Analysis 
The  current  status  of  the  effort  is  that  the  above  environment  is  about  30%  complete. 
Baseline  information  and  a  product  model  available.  The  initial  damage  prediction 
module  is  expected  to  be  provided  by  the  Navy  (DOMINO)  and  more  work  will  be 
required  for  further  understanding  of  how  this  enabler  can  be  integrated  in  the  process. 


Future  Work 

Except  for  the  integration  of  DOMINO  in  the  M&S  environment,  further  efforts  arc 
required  for  the  systems  modeling  and  integration.  While  power  system  and  cooling 
system  models  are  available,  the  IRIS  team  is  currently  working  to  validate  the  integrated 
environment  that  has  been  constructed.  Furthermore,  an  infrastructure  concerning  the 
processing  of  simulation  responses  needs  to  be  finalized.  This  will  allow  for  various  tasks 
to  be  performed,  such  as  design  space  exploration,  decision  making  on  design 
enhancements,  etc. 
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Subtask  5.3:  Development  and  evaluation  of  a  complete  method 
Introduction 

With  the  emergence  of  the  previous  capabilities,  a  complete  method  will  be  developed 
and  tested  on  a  small  scale  YP-679  naval  system.  With  task  3,  the  theoretical  framework, 
combined  with  the  analysis  environment  will  become  the  main  elements  of  the 
survivability  based  design  methodology.  The  final  solution  should  be  the  one  that 
satisfies  top  level  performance  constraints  subject  to  the  scenarios  considered.  Last  step 
of  the  method  development  would  be  the  application  of  scientific  techniques  for  testing 
and  evaluation  of  the  method  itself 

Progress 

The  ship  baseline  for  the  method  development  will  be  the  YP-679.  Thus,  no  concept 
exploration  will  be  part  of  this  method,  rather  than  the  exploration  of  the  design  space  for 
ensuring  flexibility  in  the  ease  that  system  requirements  might  be  altered.  For  the  purpose 
of  demonstrating  how  this  method  can  yield  a  more  resilient  design,  a  specific  approach 
has  been  accepted  as  a  means  of  method  verification.  Three  designs  will  be  produced 
originating  from  the  same  baseline,  yet  they  will  be  optimized  for  different  objectives. 
One  will  just  be  a  performance  oriented  design.  The  second  will  encompass  survivability 
enhancement  features  but  not  necessarily  any  enabling  capabilities  for  a  more  resilient 
design  (e.g.  like  an  IRIS  system).  The  third  approach  will  be  a  more  resilient  design, 
which  would  be  capable  of  reconfiguring  and  demonstrating  intelligent  responses  to  the 
same  set  of  test  scenarios.  Ultimately,  the  three  designs  will  be  compared  in  terms  of  their 
performance  in  safety  and  survivability  along  with  any  increase  in  system  complexity  and 
design  cost. 

Future  Work 

While  strategies  for  method  development  and  verifieation  have  been  iterated  upon  and 
finalized,  the  bulk  of  the  work  for  aetually  produeing  the  three  designs  and  evaluating 
them  against  each  other,  is  still  part  of  the  future  work  for  the  remainder  of  this 
agreement. 
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Appendix 


Figure  17:  Activity  Diagram  for  “Generate  Baseline  Concept” 
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Figure  18:  Activity  Diagram  for  ‘‘Analyze  System” 
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Figure  19:  Activity  Diagram  for  “Evaluate  Abilities” 
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Figure  20:  Activity  Diagram  for  “Modify  Design” 


26 


X 


Create  Surrogates  of  M&S 


Create  Design 


t 


\/ 


\f 


Populate  Design  Spac^ 


\/ 


Store  design  Info  in  database 


Y 

(D 


Figure  21:  Activity  Diagram  for  “Store  Design” 
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Cost  Expenditure  Status  Report 


Figure  22  shows  the  projected  expense  (based  on  the  total  budget  of  $155,305)  over  the 
contract  period  and  actual  expense  for  the  month  of  July,  August  and  September.  We  are 
trying  to  keep  our  cost  on  the  target.  The  difference  between  the  projected  and  actual 
expenses  is  due  to  the  fact  that  the  completed  travel  cost  has  not  been  reflected  in  this 
summary  and  potential  travel  has  not  been  scheduled. 
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Figure  22:  Cost  Expenditure  Status 
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